home *** CD-ROM | disk | FTP | other *** search
/ Dr. Windows 3 / dr win3.zip / dr win3 / PROGRAMR / ASM32PM.ZIP / PMODE.DOC < prev    next >
Text File  |  1993-06-07  |  48KB  |  925 lines
  1. Warning:
  2.   This document is intended for the experienced programmer with knowledge of
  3. a good deal of assembly and the 386. If you are not one such person, the text
  4. that follows will be very confusing to you. Read on if you wish... You have
  5. been warned.
  6.  
  7. ------------------------------------------------------------------------------
  8. Some crap:
  9.  
  10.   This is the doc for PMODE v1.29a. I am not going to rewrite it just for
  11. version 2.1232 since almost all of this doc applies perfectly. There are a few
  12. changes from PMODE 1.29a to 2.1232 however. They follow at the end of this
  13. doc.
  14.  
  15.   This code, as well as this doc (damn I hate writing dox), were written up
  16. by Tran (a.k.a. Thomas Pytel) of Renaissance. It is intended for all those of
  17. you out there who would like to code in protected mode, but keep running up
  18. against obstacles. If you want to use this thing as it is though, you will
  19. have to code in 100% ASM. But hey, that's no problem. I do it all the time. I
  20. did write this thing for myself. So if you have a problem with it, tough. You
  21. have a few options. You can use it as it is, and code in all ASM (not a
  22. terribly difficult feat). You can examine the code, and use what you learn to
  23. code up your own protected mode system, one that you can maybe throw into a
  24. nice high level language maybe. Or you can just ignore this code and this doc.
  25.  
  26. ------------------------------------------------------------------------------
  27. Intro:
  28.  
  29.   Ah... many are the joys and woes of this chip we all know as the 386. The
  30. 486 - bah, just a 386 with a cache. The 586 - hahaha, two 486s with double the
  31. cache. But the wonderful 386 architecture. That finally gives us our needed
  32. flat memory. Not to mention the paging (not a personal favorite, but VERY
  33. useful). It's been around here for a while now, but it hasn't been used very
  34. much. I'm assuming you know all the problems associated with sharing the
  35. 386 protected mode amongst different programs. So I'll just go on to tell ya
  36. about two methods of doing this, VCPI and DPMI.
  37.  
  38.   In the beginning (or at least a long time ago). There was the EMS and the
  39. XMS. Two pathetic attempts by the hopelessly crippled (design-wise) 8086s and
  40. 286s. EMS and XMS were fine for accessing small chunks of a larger address
  41. space at a time. These methods were usually very slow. As for XMS, the 286
  42. actually had to copy memory every time it was requested. And hardware EMS
  43. resided on the slow system bus (well, not that much slower compared to the
  44. speed of those machines). With the introduction of the 386, and soon the
  45. memory managers, things changed. EMS and XMS could now be handled with the
  46. on-chip paging mechanism. Which was faster than the memory copy method, and
  47. even the hardware EMS. But for this task, the memory managers had to run the
  48. system in V86 mode. Forsaking all other programs which would want to take
  49. control of the 386 protected mode.
  50.  
  51.   Thus was devised VCPI. A method of allowing programs running in the V86
  52. system to switch to protected mode. After switching to protected mode, those
  53. programs would have total control of the system. Running at a privilege level
  54. of 0. They could communicate with the other protected mode program, the VCPI
  55. server, through a common memory address space starting with the first megabyte
  56. of memory. VCPI was a superset of the EMS standard, and was implemented in
  57. virtually all memory managers and 386 extenders. But VCPI was woefully
  58. inadequate for the multitaskers that were soon to follow.
  59.  
  60.   Then there came forth the DPMI standard. Born from the window, it is the
  61. epitome of total lameness. Many are the unknowing peons who run the window.
  62. And many are the lamer who do not know the purpose of our favorite key
  63. combination, the CTRL+ALT+DEL. A wondrous function of that eternal TSR called
  64. the BIOS. Many a fool activate it whilst on a local BBS, erroneously believing
  65. they will get free downloads. But I digress, we were all lame at one time or
  66. another. This standard of the DPMI was different from those of antiquity.
  67. This foul interface was designed with total control in mind. Total control
  68. by the evil host whose lameness was imposed upon all those running beneath it.
  69. At a lowly CPL3, this loathsome beast's clients are truly at a disadvantage.
  70. Their INs and OUTs under the thorough scrutiny of the master. Forced to
  71. grovel for precious memory. Not even their own instructions are sacred. For
  72. the fiend which is DPMI, patiently waits, and watches. Ready to tear the
  73. precious life from the pitiable client at the slightest sign of the forbidden
  74. CLI. Then the monster does its deeds, toggling an illusion of that which was
  75. once real. This virtual flag of interrupts ensures the depraved host total
  76. domination. So easy to hate it is this beast. But yet... In the name of
  77. multiple tasking, and system integrity. The DPMI continues to gain ground.
  78. (Well sure, if ya want those things. But where is your adventure... Your
  79. spirit... Have you totally forgotten what a good crash feels like???)
  80.  
  81.   These days, VCPI and DPMI permeate the world of 386 software. From memory
  82. managers, to Windows and OS/2. If something is protected, its using one of
  83. these. VCPI though, is on its way out. Being replaced by DPMI. And if you want
  84. to code protected mode... Unless you force upon the user a clean boot, you
  85. have to support one of these two standards.
  86.  
  87. ------------------------------------------------------------------------------
  88. So what you got here:
  89.  
  90.   Having coded raw flat protected mode, I am hooked. I shall not revert to
  91. real mode limitations. My previous protected mode system 'START32' was very
  92. intolerant of crap like VCPI and DPMI and EMS and XMS and everything else. It
  93. required a clean boot to function. But hey, for that I got pure wonderful
  94. flat protected mode. Unfortunately, the masses did not share my sentiment.
  95. And they whined about rebooting. Pitiful as they were, I have heard their
  96. cries. And I understand. The culmination is the code before you (or rather in
  97. the other file, PMODE.ASM). This is basically the same pure beautiful flat
  98. protected mode system as my old START32 system, except that it will run under
  99. VCPI and DPMI and XMS (albeit a little slower).
  100.  
  101. ------------------------------------------------------------------------------
  102. What it thinks it does:
  103.  
  104.   The point of this protected mode header thingy is to provide a simple, flat
  105. mode environment for easy assembly coding. PMODE will take care of detecting
  106. a 386, the type of system (raw,XMS,VCPI,or DPMI) and making sure there is
  107. enough memory, both low and high. The protected mode code runs in one big
  108. segment, the size of which is infinite (or 4GB, whichever is larger). You can
  109. call real mode interrupts of far routines from your pmode code. And those
  110. in turn can call back to protected mode. And on and on like this to the limits
  111. of the stack. Once in pmode, all normal IRQs are still active and are by
  112. default, redirected to their real mode handlers. You can intercept these
  113. IRQs for your own use, then pass them on to the real mode handlers or not.
  114.  
  115.   This system was coded with speed in mind. It is meant for stuff like games,
  116. demos (as in the ones with cool muzik and grafix), or stuff that needs a lot
  117. of memory. What you should not attempt from this system, is going TSR, or
  118. executing DOS programs. This system runs absolutely perfectly for what it was
  119. meant for in raw and XMS. There are some minor problems under VCPI and DPMI
  120. though, and i'll list them later. But right now...
  121.  
  122. ------------------------------------------------------------------------------
  123. First of all, the structure:
  124.  
  125.   In PMODE.ASM, there are three segments. They are as follows:
  126.  
  127. ) CODE16 - A 16bit segment that holds all the real mode and 16bit protected
  128.            mode init and exit code. I'm not sure (I've forgotten by now), but
  129.            you should probably leave it as the first segment of the EXE.
  130. ) CODE32 - The huge 32bit segment. You can throw in as much code as will fit
  131.            in low memory (no 64k fixup overflows). If you need more code
  132.            space, you're gonna have to load it into extended